Thanks, here are my initial thoughts.

Pluggable RowKeyProgress feels like overkill

Allowing a custom class gives maximum flexibility, but I think few users will author and deploy a custom class just for an optional progress signal. It costs us an @InterfaceAudience.Public interface to maintain. Could we drop it and pick the algorithm via a simple string config (e.g. uniform / hex)?

Please let me know if you have a plan to use a custom implementation.

Naming could align with RegionSplitter

Users already know HexStringSplit, UniformSplit, and DecimalStringSplit from RegionSplitter. But this PR introduces new vocabulary (HexPrefix, ByteBased) for the similar, albeit not identical, concepts. Can we reuse the existing words?

Generalize HexPrefix to handle any-length hex keys (HexString?)

Would it be possible to simplify your HexPrefix implementation so that users don't have to specify a prefix? Some tables might have rowkeys that consist entirely of hex strings, and it can be confusing for them to specify a prefix. I think we can simplify the model and clamp bytes that go beyond the hex string boundary. For example:

• startrow: a1
• rowkey: bea\x200\x201\x202
• stoprow: cf123

becomes

• a10000
• beafff
• cf1230

for comparison.

@junegunn Thank you for your feedback.

Pluggable RowKeyProgress feels like overkill

Thank you for raising this! I agree the abstraction comes with a real maintenance cost, and a string-config switch is appealing.

The reason I'd like to keep the pluggable interface is that we have a concrete in-house use case where the row-key salt follows a [a-z][0-9]{N} pattern. Neither uniform nor hex reports a sensible curve for that schema (the byte-level interpretation under-reports through most of the alphabet, and the hex interpretation collapses every key past f to zero). With the pluggable interface, we can just ship a small custom implementation. Otherwise, users with similar non-uniform (but not quite hex) schemas would be stuck needing a follow-up patch.

Naming could align with RegionSplitter

Great point. I hadn't connected it to RegionSplitter clearly enough. Renamed:

• ByteBasedRowKeyProgress → UniformRowKeyProgress
• HexPrefixRowKeyProgress → HexStringRowKeyProgress

Generalize HexStringRowKeyProgress to handle any-length hex keys (HexString?)

Thank you, this was the right call. Removed the hbase.mapreduce.rowkey.progress.hex.prefix.length config. the class now auto-derives the prefix length from the start/stop rows (longest common prefix + a small resolution margin, capped to fit double precision). Non-hex trailing bytes contribute zero:

• startrow a1 → a10000
• rowkey bea\x20\x20\x21\x22 → bea0000
• stoprow cf123 → cf1230

No prefix length to tune, and works for both pure-hex and hex-prefixed strings.

I've just fixed test failures in TestTableRecordReader and TestTableInputFormat